feat(prost-derive): skip field attribute #1339
Conversation
maxpowa
changed the title
maxpowa
force-pushed
the
skip-fields
branch
2 times, most recently
from
9f99c58 to
9412bfb
Compare
maxpowa
changed the title
caspermeijn
left a comment
caspermeijn
left a comment
There was a problem hiding this comment.
I like the skip option. I see how this could be useful when using prost-derive.
I am not sure how I feel about the default attribute. Why doesn't each of the skipped types implement default?
I miss tests. You could take some inspiration from tests/src/custom_debug.rs or prost-derive/src/lib.rs.
I miss documentation. The documentation of derive attributes is not great, but this new attr should at least be mentioned in README.md
The |
This will make prost ignore the field during serialization and deserialization. The field must implement the "Default" trait for this to work properly.
Prevents the skipped field from needing to implement the `Default` trait.
Usage:
```rs
struct Test {
#[prost(int32, tag = "1")]
a: i32,
#[prost(skip)]
c: i32,
#[prost(skip, default = "create_foo")]
d: Foo,
}
struct Foo(i32);
pub fn create_foo() -> Foo {
Foo(12)
}
```
The `default` keyword was being picked up by the skip handler for fields which weren't tagged with the `skip` attribute.
2 participants
This change will allow Prost users to skip a field during serialization and deserialization. It also provides an optional
defaultattribute for these fields, in the event the underlying object does not implement theDefaulttrait.My motivation for this is some reverse engineering effort, in which the existing datastructures are serialized in both protobuf and xml formats. I can use
quick_xml/serdeand ignore protobuf-only fields, but I can't ignore xml-only fields usingprost, which results in duplicate data structures and more boilerplate to convert between the two types.Usage:
Related: #174
This appears to work locally, but I can't get the full test suite to run (even with clean main branch). I'd like to add some integration tests for this, but it seems the only tests for derive currently are the existing Protobuf known-types (where this wouldn't really make sense), and a few negative test cases in the derive package.